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1.  Introduction 


1,1  Background 

The  Wireless  Emulation  Laboratory  (WEE)  of  the  El.S.  Army  Researeh  Laboratory  (ARE)  exists 
to  support  researeh  in  wireless  mobile  networks  and  mobile  ad-hoe  network  (MANET)  seeurity 
(1)  and  to  demonstrate  ARL-developed  solutions.  A  key  eomponent  of  the  WEE  is  an  emulation 
test  bed,  whieh  is  based  on  the  Mobile  Ad-hoe  Network  (MANET)  Emulator  (MANE) 
arehiteeture  that  was  originally  developed  by  the  El.S.  Naval  Researeh  Laboratory  (NRL)  (2). 

The  MANE  system  eonsists  of  hardware  and  software.  The  hardware  system  is  a  sealable  high- 
performanee  network  of  physieal  eomputers.  The  software  system  enables  the  emulation  of  a 
dynamie  MANET  by  managing  and  exeeuting  the  effeets  of  mobility  on  network  eonneetivity. 
Effeetively  it  ereates  virtual  network  topologies  that  evolve  with  time,  a  dependent  variable  of 
mobility. 

Mobility  is  about  ehanges  of  the  geodetie  positions  of  the  partieipating  mobile  nodes  over  a  fixed 
time  interval,  i.e.,  a  mobility  seenario.  The  geodetie  positions  of  eaeh  node  are  predetermined, 
arranged  in  aseending  order  by  time,  and  stored  in  a  log  file,  whieh  is  basieally  a  text  file 
eontaining  the  mobility  traees  of  a  mobile  node.  The  log  files  are  usually  ereated  off-line  using 
the  ARE  Topodefi’’^  tool  (5),  a  graphieal  system  and  method  for  visually  ereating  and  editing 
speeifie  network  topologies  of  an  emulated  MANET.  A  network  topology  is  a  snapshot  in  time 
showing  the  number  of  partieipating  nodes,  their  relative  geographieal  positions  on  the  sereen, 
and  their  intereonneetions  or  eommunieation  links.  A  eustom-designed  network  topology 
eonsists  of  a  predetermined  number  of  nodes  being  plaeed  at  exaet  loeations  and  a  desirable  set 
of  eommunieation  links. 

A  eommunieation  link  between  a  pair  of  any  two  nodes  depends  on  the  range  of  their  equipped 
radios.  A  link  is  established  whenever  one  of  the  radios  ean  intelligibly  reeeive  the  signal 
transmitted  by  the  other  radio  and  deeonstrueted  if  it  eannot.  When  both  ean  intelligibly  reeeive 
signals  from  one  another’s  radio,  a  bidireetional  link  is  established.  The  range  is  now  eomputed 
using  the  values  of  their  radio  parameters  over  the  horizontal  distanee  (line-of-sight)  between 
two  nodes.  The  radio  parameters  inelude,  but  are  not  limited  to,  radio  frequeney,  transmitting 
power,  and  reeeiving  sensitivity.  Computing  the  range  is  performed  by  the  range  model  (RM) 
eomponent  of  the  MANE  software  system.  The  RM  eomponent  relies  on  the  Geodesy 
Eoundation  Classes  (GEC)  (4)  to  ealeulate  the  geodetie  distanees  that  are  needed  in  the 
determination  of  the  network  eonneetivity  between  a  pair  of  two  nodes. 

The  ARE  Topodefi’’^  tool  also  ealeulates  the  range  between  a  pair  of  every  two  nodes  to 
determine  a  possible  eommunieation  link,  whieh  is  neeessary  for  the  ereation  of  a  network 
topology.  The  tool  then  extraets  the  time-dependent  geodetie  positions  of  eaeh  node  from  the 
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generated  network  topologies  and  reeords  them  in  the  log  files.  Providing  the  MANE  software 
system  with  these  log  files  should  reereate  the  same  network  topology  in  the  test  bed  as  they 
have  been  designed  and  verified.  Therefore,  having  consistent  results  of  geodesic  distances 
calculated  in  the  tool  and  in  the  MANE  software  system  is  imperative  for  a  successful  emulation 
of  a  dynamic  MANET  as  intended. 

To  achieve  this  objective,  the  same  algorithm  and  its  implementation  for  calculating  the  distance 
between  two  geodetic  locations  should  be  used  in  the  ARE  Topodefi'’^  tool  and  in  the  MANE 
system.  The  implementation  of  this  solution  has  two  options:  (1)  selecting,  implementing,  and 
integrating  an  appropriate  algorithm  into  the  tool  and  in  the  MANE  system,  or  (2)  using  an 
implementation  that  has  already  been  integrated  in  the  MANE  system.  Between  the  two  options, 
the  latter  requires  lesser  effort  by  leaving  the  MANE  software  system  intact  and  by  creating  a 
Python  (5)  extension  to  the  GFC  library,  which  consists  of  C++  classes. 

1.2  Scope 

This  report  describes  the  successful  development  of  the  pyGFC  module,  a  Python  extension  that 
enables  the  integration  and  use  of  C++  classes  and  methods  in  a  Python  application,  the  ARE 
TopodeB’^  tool.  The  intended  purposes  of  this  report  are  to: 

•  Describe  and  discuss  the  method  used  in  the  development  of  the  pyGFC  module 

•  Identify  other  development  tools  and  methods  for  creating  Python  extensions  to  C++ 

•  Document  the  application  programming  interfaces  of  the  pyGFC  module 

The  rest  of  this  report  is  organized  in  the  order  of  its  intended  purposes.  The  next  section, 
section  2,  presents  and  discusses  the  method  that  was  used  to  create  the  pyGFC  module  and 
briefly  describes  other  development  tools  and  methods  for  creating  Python  extensions  to  C++ 
libraries.  Section  3  summarizes  the  findings  and  concludes  the  report. 

1.3  Method 

The  development  of  the  pyGFC  module  used  software  development  tools  that  came  with  the  Red 
Hat  Enterprise  operating  system  and  on  the  information,  tutorials,  and  usage  instructions  that 
were  available  on  the  Web.  An  objective  of  the  development  was  to  minimize  the  development 
effort,  the  modification  to  the  host  environment,  and  the  costs  of  administrative  overhead 
associated  with  the  acquisition,  installation,  and  configuration  of  additional  software  systems. 
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2.  The  pyGFC  Module  Development 


•  The  pyGFC  module  was  ereated  on  a  computer  running  the  Red  Hat  Enterprise  Linux® 
operating  system.  All  the  tools  needed  for  the  creation  of  the  module  were  already 
available  in  the  host:  (i)  the  GFC  source  code,  (ii)  the  SWIG  command,  and  (ill)  the  ar 
archive  program,  and  (iv)  the  C++  compiler. 

•  The  GFC  files  came  with  the  MANE  software  system,  and  the  last  two  were  already 
included  in  the  Linux  OS  packages.  The  SWIG  command  whose  name  was  derived  from  its 
longer  name  reflecting  its  functionality:  the  Simplified  Wrapper  and  Interface  Generator 
(SWIG)  development  tool.  SWIG  facilitates  the  use  of  C/C++  functionality  from  other 
languages  among  them  is  the  Python  programming  language.  It  is  usually  included  in 
Linux  and  Cygwin  (6)  distributions  and  also  available  separately  for  downloading  and 
installation  in  other  operating  environments,  e.g.,  Microsoft  Windows®  operating  systems 
and  Minimalist  GNU  for  Windows  (MinGW)  (7). 

•  The  ar  archive  program  was  used  to  organize  and  combine  multiple  files  into  a  single  file,  a 
library.  The  C++  compiler  was  used  to  translate  the  C++  source  files  into  object  code  and  to 
create  the  shared  library  needed  by  the  pyGFC  module. 

2,1  Platform  Identification  and  Tool  Versions 


The  information  about  the  platform  and  the  version  of  the  tool  was  retrieved  using  the  following 
commands  and  options  that  were  typed  into  a  console  window. 


/bin/uname  -r  -o 
/usr/bin/c++  --version 
/usr/bin/ar  -version 
/usr/bin/swig  -version 


2.6.18-8.el5  GNU/Linux 
C++  (GCC)  4.1.1  20070105  (Red  Hat  4.1.1-52) 
GNU  ar  2.17.50.0.6-2.el5  20061020 
SWIG  Version  1.3.29 


The  version  of  the  GFC  files  was  embedded  in  the  source  files,  and  they  were  the  same  although 
they  had  different  modification  time: 

CEarth.cpp  Revision:  1.1. 1.1  Modtime:  9/01/98  9:56p 

CEarthCoordinate.cpp  Revision:  1.1. 1.1  Modtime:  2/07/98  10:34a 
CPolarCoordinate.cpp  Revision:  1.1. 1.1  Modtime:  2/07/98  10:35a 

2,2  Files  and  Directories 

The  development  of  the  pyGFC  module  using  the  SWIG  command  required  the  creation  of  the 
following  files: 
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•  The  pyGFC.cpp  file  and  its  corresponding  header  file,  pyGFC.h.  The  files  define  the 
GFCCoord  elass  interfaeing  direetly  with  the  GFC  library  to  ealeulate  geodetie  distanees 
and  providing  Python  applieations  a  way  to  use  geodetie  eomputing  services.  Although 
these  two  fdes  were  not  required  by  SWIG,  they  were  custom-created  to  support  the  use  of 
the  GFC  library  in  the  ARL  Topodefi’’^  tool  and  other  Python  applications  that  dealt  with 
geodetic  coordinates. 

•  The  pyGFC.i  interface  file.  The  contents  of  the  pyGFC.i  fide  specify  the  required  header 
files  for  the  creation  of  the  wrapper  file  and  expose  all  the  functions  of  the  GFC  library,  the 
GFCCoord  class,  and  the  error  functions  that  were  available  in  the  standard  C  math  library, 
but  excluded  from  the  Python  math  module.  The  SWIG  command  then  followed  the 
specifications  in  the  pyGFC.i  file  to  create  two  files:  a  Python  file  and  a  C++  file.  The  C++ 
file  wraps  the  GFC  library,  and  the  Python  file  provides  transparent  functionality  of  the 
GFC  library  in  Python  applications. 

The  three  files  were  placed  in  the  pygfc  directory,  which  also  had  the  GFC  subdirectory 
containing  the  original  GFC  source  code  as  shown  below: 

n  pygfc 

1  pyGFC.i 
1  pyGFC.h 
1  pyGFC.cpp 
a  GFC 

1  CMath.inl 
1  CMath.hpp 
1  CEarth.hpp 
1  GFC.h 

1  CPolarCoordinate.cpp 
1  CEarthCoordinate.cpp 
1  CEarth.cpp 


2,3  Procedure 

The  procedure  for  creating  the  pyGFC  module  consisted  of  five  steps.  Each  step  produced  one  or 
more  files,  which  were  then  needed  for  subsequent  steps.  Eigure  1  illustrates  the  procedure  by 
showing  connected  block  diagrams  of  processes  and  their  required  input  and  output  files.  At  the 
end,  only  two  files  are  needed  by  a  Python  application:  the  shared  library  file  pyGFC.so  and  the 
Python  wrapper  fide  pyGFC.py. 
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Figure  1.  Procedure  for  creating  the  pyGFC  module. 

•  Step  1 :  Creating  the  GFC  library  using  the  C++  compiler  and  the  ar  commands; 


GFC  Files 
(* *.cpp,  *.hpp) 


Create  the  GFC  library 

cd  GFC 

C++  -I.  -I/usr/include  -c 
C++  -I.  -I/usr/include  -c 
C++  -I.  -I/usr/include  -c 
ar  -rev  libgfc-linux.a  CEarth.o 
CEarthCoordinate .o  CPolarCoordinate 
rm  -f  CEarth.o  CEarthCoordinate . o 
CPolarCoordinate . o 
cd  .  . 


CEarth. epp 

CEarthCoordinate . epp 
CPolarCoordinate . epp 


libgfc-linux.a 


Figure  2.  Creating  the  GFC  library. 


•  Step  2:  Creating  the  pyGFC. epp  file,  its  corresponding  pyGFC. h  file,  and  the  pyGFC. i 
interface  file  using  a  text  editor,  e.g.,  vi.  The  pyGFC. i  file  contains  the  directives  for  the 
SWIG  command;  the  header  files  that  are  needed  by  the  wrapper  file  and  the  interfaces  that 
are  made  available  to  a  Python  application.  In  this  development,  the  interfaces  are 
specified  in  the  pyGFC. h,  which  is  then  included  in  the  pyGFC. i.  Appendix  B  lists  the 
source  code  of  these  files. 

•  Step  3;  Creating  wrapper  files  using  the  SWIG  command.  SWIG  took  in  the  pyGFC. i  file 
and  produced  two  files;  the  pyGFC. py  and  the  pyGFC_wrap.cxx  files. 


5 


pyGFC.i 


pyGFC.  py 

Create  a  C++  wrapper  for  Python 
swig  -C++  -python  -I  GFC  pyGFC.i 

pyGFC_wrap.cxx 

Figures.  Generating  wrapper  files. 


•  Step  4:  Compiling  the  pyGFC_wrap.cxx  and  the  pyGFC.cpp  files  using  ; 


1  ' 

Compile  the  wrapper  files 

1  '  - 

pyGFC.cpp 

C++  pyGFC  wrap . cxx  pyGFC . cpp 

pyGFC. o 

pyGFC_wrap.cxx 

-I/usr/local/include/python2 .5 

pyGFC_wrap.o 

-I./GFC  -I.  -c 

Figure  4.  Compiling  the  wrapper  files. 

•  Step  5:  Creating  the  pyGFC  library  using  the  C++  compiler; 


pyGFC*.o 

libgfc-linux.a 


Create  a  shared  library 

G++  pyGFC. o  pyGFC_wrap.o  -L./GFC  -Igfc-linux 
-L/usr/local/lib/python2 . 5/conf ig 
-lpython2.5  -shared  -o  j)yGFC.so 


pyGFC.  so 


Figure  5.  Creating  the  shared  library. 

2.4  Result  &  Discussion 

The  development  of  the  pyGFC  module  was  straightforward  and  relatively  smooth  because  the 
interfaces  to  the  GFC  library  were  simple,  and  throughout  the  process,  only  a  minor  syntactical 
error  in  the  SWIG-generated  pyGFC  wrap.cxx  file  was  encountered  and  easily  fixed.  The 
following  lines  show  the  errors  and  how  they  were  fixed; 

$  C++  pyGFC_wrap . cxx  pyGFC.cpp  -I/usr/local/include/python2 . 5  -I. /GFC  -I.  -c 
pyGFC  wrap.cxx:  In  function  ‘int  SWIG_Python_ConvertFunctionPtr(PyObject*,  void**,  swig  typejnfo*)’: 

pyGFC_wrap.cxx:2051:  error:  invalid  conversion  from  ‘const  char*’  to  ‘char*’ 

pyGFC  wrap.cxx:  In  function  ‘void  SWI G_Python_FixMethods(Py Method Def*,  swig  constjnfo*, 
swig  typejnfo** ,  swig  ty pe_i nfo** )’ : 

pyGFC_wrap.cxx:7961:  error:  invalid  conversion  from  ‘const  char*’  to  ‘char*’ 

These  two  errors  that  occurred  in  line  numbers  2051  and  7961  were  of  the  same  category.  Fixing 
them  required  the  use  of  a  text  editor  to  insert  the  expression  (char  *)  to  the  lines  that  caused 
the  error  as  shown  in  the  following  two  lines; 

2051  char  *doc  =  (char  *) ( ( (PyCFunctionObj ect  *)obj)  ->  m_ml  ->  ml_doc) ; 
7961  char  *c  =  (char  *)  methods [i] .ml_doc; 
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Once  the  problem  had  been  fixed,  the  process  continued  without  a  hitch.  The  final  phase  was  to 
test  the  newly  created  pyGFC  module  in  a  Python  development  environment,  the  Python’s 
Integrated  Development  Environment  (IDLE).  Eigure  6  is  the  screen  dump  of  a  Python 
interaetive  session  that  imported  the  pyGFC  module,  showing  four  different  aetions  performed  to 
ensure  the  operability  of  the  module: 

•  Displaying  the  contents  of  the  pyGFC  module.  All  the  C++  elasses  defining  the  GEC  library 
are  available  as  they  are  listed  on  the  screen,  e.g.,  CEarth,  CEarthCoordinate, 

CPolarCoordinate . 

•  Ensuring  that  the  erf  and  the  erfc  functions  would  work  correctly.  The  sum  of  erf(x)  and 
erfc(x)  equals  1.0  because  erfc(x)  =  1  -  erf(x)  by  definition. 

•  Displaying  the  attributes  and  methods  of  the  GFCCoord  class;  e.g.,  alt,  lat,  Ion,  get  distance. 

•  Setting  two  geodetie  locations  and  calculating  the  distanee  between  them. 
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Figure  6.  Results  -  an  interactive  session  with  the  pyGFC  module. 

2,5  Other  Development  Tools  for  Creating  Python  Extensions  to  C++ 

In  addition  to  the  SWIG  development  tool,  several  other  open-source  tools  for  creating  Python 
extensions  are  available  on  the  Web.  They  include  but  are  not  limited  to  Boost.Python,  PyRex, 
PyCXX,  and  Weave.  A  brief  description  of  what  they  are  is  included  in  this  section.  More 
detailed  description  and  usage  instructions  can  be  obtained  from  their  respective  Web  sites 
(appendix  A). 
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•  Boost.Python  emerges  as  a  eompetent  development  tool  for  the  development  of  Python 
extensions  to  C/C++.  Using  Boost.Python  requires  extensive  knowledge  of  the  C++ 
programming  language,  espeeially  the  C++  templates. 

•  PyCXX  appears  to  be  a  eapable  development  tool  whose  prineipal  goal  is  to  ease  the 
writing  of  Python  extensions. 

•  PyRex  enables  the  mixing  of  Python  and  C/C++  in  a  Python  program  using  its  own 
language  whieh  is  very  similar  to  Python  and  C;  therefore,  PyRex  itself  is  a  eomputer 
language. 

•  Weave  also  enables  the  mixing  C/C++  eode  in  a  Python  program  to  improve  its 
performanee  and  to  generate  Python  extensions. 


3.  Summary 


The  ereation  of  the  pyGFC  module  using  SWIG  was  relative  easy  on  a  Linux®  environment 
beeause  the  interfaees  to  the  GFC  library  were  simple.  The  deseribed  multi-step  proeedure  is 
expeeted  to  reproduee  the  same  results  in  a  Linux-like  environment;  for  example,  Cygwin  and 
MSYS/MinGW  environments. 
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Appendix  A.  URL  of  Development  Tools 


SWIG 

PyRex 

Boost.Python 

PyCXX 

Weave 


http://www.swig.org 

http://www.eose.eanterbury.ae.nz/greg.ewing/python/Pyrex 

http://www.boost.org 

http://souroeforge.net/projeots/oxx/ 

http://www.soipy.org/Weave 
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Intentionally  Left  Blank. 
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Appendix  B.  Source  Files 


Table  B-1.  The  pyGFC.h  file. 

#ifndef  PYGFC 
#define  PYGFC 

#include  <iostream> 

#include  "GFC.h" 

using  namespace  std; 

#define  ONE  MINUTE  METERS  (1852.0) 

#define  ONE  DEGREE  METERS  (60.0  *  ONE  MINUTE  METERS) 

#define  COORD  STRLEN  (64) 

class  GFCCoord 

{ 

public : 

GFCCoord (  const  GFCCoord  *  )  ; 

GFCCoord (double  lat=0.0,  double  lon=0.0,  double  alt=0.0); 
virtual  -GFCCoord () ; 

void  set (const  GFCCoord  *); 

void  set (double  ,  double  ,  double) ; 

void  print  coords ( ) ; 

char  *get  coords  str(); 

double  get  distance (const  GFCCoord  *  ); 

double  get  distance (const  GFCCoord  *,  const  GFCCoord  *); 

double  estimate  latitude  coord (  GFCCoord  *,  double); 
double  estimate  longitude  coord (  GFCCoord  *,  double); 
GFCCoord  *estimate  southeast  coords (double ,  double); 

double  lat; 
double  Ion; 
double  alt; 

private : 

CEarth  *earth; 
char  *cstr; 

}; 

#endif 
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Table  B-2.  The  pyGFC.cpp  file. 

ttinclude  "pyGFC.h" 

GFCCoord :: GFCCoord (double  lat,  double  Ion,  double  alt) 

{ 

this->lat  =  lat; 
this->lon  =  Ion; 
this->alt  =  alt; 
this->earth  =  new  CEarth ( ) ; 

this->cstr  =  (char  *) malloc (COORD  STRLEN) ; 

} 

GFCCoord :: GFCCoord (  const  GFCCoord  *  p  ) 

{ 

this->lat  =  p->lat; 
this->lon  =  p->lon; 
this->alt  =  p->alt; 
this->earth  =  new  CEarth () ; 

this->cstr  =  (char  *) malloc (COORD  STRLEN); 

} 

GFCCoord : : -GFCCoord ( ) 

{ 

delete  this->earth; 
delete  this->cstr; 

} 

void  GFCCoord: : set (const  GFCCoord  *  p) 

{ 

this->lat  =  p->lat; 
this->lon  =  p->lon; 
this->alt  =  p->alt; 

} 

void  GFCCoord :: set (double  lat,  double  Ion,  double  alt) 

{ 

this->lat  =  lat; 
this->lon  =  Ion; 
this->alt  =  alt; 

} 

void  GFCCoord: : print  coords ( ) 

{ 

cout  <<  " ( " 

<<  this->lat  << 

<<  this->lon  <<  " ,  " 

<<  this->alt 
<  <  " )  " 

<<  endl; 

} 

double  GFCCoord :: get  distance (const  GFCCoord  *a,  const  GFCCoord  *b) 

{ 

y**************************************************************** 

This  code  is  taken  from  the  NRL-designed  RangeDrop : : getDistance ( ) 

**************************************************************** y 

CPolarCoordinate  here,  there; 

here . SetUpDownAngleInDegrees (a- >lat ) ; 

here . SetLef tRightAngleInDegrees (a- >lon) ; 

here . SetDistanceFromSurf aceInMeters (a- >alt ) ; 

there . SetUpDownAngleInDegrees (b- >lat ) ; 
there . SetLef tRightAngleInDegrees (b- >lon) ; 
there . SetDistanceFromSurf aceInMeters (b- >alt ) ; 

return  this->earth->GetLineOfSightDistance (here, there) ; 

} 

char  *GFCCoord : : get  coords  str() 

{ 

sprintf  (this- >cstr ,  ''(%.8f,  %.8f,  %8f)'',  this->lat,  this->lon,  this->alt); 

return  this->cstr; 

} 

double  GFCCoord :: get  distance (const  GFCCoord  *  p) 

{ 

return  this->get  distance (this ,  p) ; 

} 

double  GFCCoord :: estimate_latitude_coord (  GFCCoord  *p,  double  target_distance  ) 
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/***  estimate  the  latitude  that  is  SOUTH  of  where  p  is  */ 

CPolarCoordinate  here; 
here . SetUpDownAngleInDegrees (p- >lat ) ; 
here . SetLef tRightAngleInDegrees (p- >lon) ; 
here . SetDistanceFromSurf aceInMeters (p- >alt ) ; 

GFCCoord  *e  =  new  GFCCoord (  p  ) ; 

/*  estimate  the  latitude  then  adjust  it  later.  */ 

e->lat  =  p->lat  -  target  distance/ (double) ONE  DEGREE  METERS; 

CPolarCoordinate  there; 

there . SetUpDownAngleInDegrees (  e->lat  ); 
there . SetLef tRightAngleInDegrees (  e->lon  ); 
there . SetDistanceFromSurf aceInMeters (  e->alt  ); 

/*  dlat  =  value  used  for  incrementingly  searching  for  the  closest  value  */ 
double  dlat  =  -O.OIO/ONE  DEGREE  METERS; 

double  est  dist  =  this->earth->GetLineOfSightDistance (here, there) ; 
if  (  est  dist  >  target  distance  )  dlat  =  -1.0  *  dlat; 

while  (  est  dist  <  target  distance  ) 

{ 

e->lat  +=  dlat; 

there . SetUpDownAngleInDegrees (e- >lat  ) ; 

est  dist  =  earth->GetLineOfSightDistance (here, there) ; 

} 

return  e->lat; 

} 

double  GFCCoord :: estimate  longitude  coord (  GFCCoord  *p,  double  target  distance) 

{ 

/***  estimate  the  longitude  that  is  EAST  of  where  p  is  */ 

CPolarCoordinate  here; 
here . SetUpDownAngleInDegrees (p- >lat ) ; 
here . SetLef tRightAngleInDegrees (p- >lon) ; 
here . SetDistanceFromSurf aceInMeters (p- >alt ) ; 

GFCCoord  *e  =  new  GFCCoord (  p  ) ; 

/*  estimate  the  longitude  then  adjust  it  later.  */ 

e->lon  =  p->lon  +  target  distance/ (double) ONE  DEGREE  METERS; 

CPolarCoordinate  there; 
there . SetUpDownAngleInDegrees (e- >lat  ) ; 
there . SetLef tRightAngleInDegrees (e- >lon  ) ; 
there . SetDistanceFromSurf aceInMeters (e- >alt  ) ; 

double  dlon  =  O.OIO/ONE  DEGREE  METERS; 

double  est  dist  =  this->earth->GetLineOfSightDistance (here, there) ; 
if  (  est  dist  >  target  distance  )  dlon  =  -1.0  *  dlon; 

while  (  est  dist  <  target  distance  ) 

{ 

e->lon  +=  dlon; 

there . SetLef tRightAngleInDegrees (e- >lon  ) ; 

est  dist  =  earth->GetLineOfSightDistance (here, there) ; 

} 

return  e->lon; 

} 

GFCCoord  *  GFCCoord :: estimate  southeast  coords (double  width,  double  height) 

{ 

/*  estimate  and  return  the  SE  corner  given  w,  h  in  meters 
width  &  height  should  be  less  than  20  km. 
caveats:  this  implementation  does  not  handle  any  location  on  earth. 

*/ 

CPolarCoordinate  here; 

here . SetUpDownAngleInDegrees ( this- >lat ) ; 
here . SetLef tRightAngleInDegrees (this- >lon) ; 
here . SetDistanceFromSurf aceInMeters ( this- >alt ) ; 

GFCCoord  *e  =  new  GFCCoord (  this  ); 

/*  estimate  the  latitude  then  adjust  it  later.  */ 
e->lat  =  this->lat  -  height/ONE  DEGREE  METERS; 

CPolarCoordinate  there; 

there . SetUpDownAngleInDegrees (  e->lat  ); 
there . SetLef tRightAngleInDegrees (  e->lon  ); 
there . SetDistanceFromSurf aceInMeters (  e->alt  ); 
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/*  dlat  =  value  used  for  incrementingly  searching  for  the  closest  value  */ 
double  dlat  =  -O.OIO/ONE  DEGREE  METERS; 

double  est  dist  =  this->earth->GetLineOfSightDistance (here, there) ; 
if  (  est  dist  >  height  )  dlat  =  -1.0  *  dlat; 

while  (  est  dist  <  height  ) 

{ 

e->lat  +=  dlat; 

there . SetUpDownAngleInDegrees (e- >lat  ) ; 

est  dist  =  earth->GetLineOfSightDistance (here, there) ; 

} 

double  saved  lat  =  e->lat; 
e->lat  =  this->lat; 

there . SetUpDownAngleInDegrees (  e->lat  ); 

e->lon  =  this->lon  +  width/ONE  DEGREE  METERS; 
double  dlon  =  O.OIO/ONE  DEGREE  METERS; 

est  dist  =  this->earth->GetLineOfSightDistance (here, there) ; 
if  (  est  dist  >  width  )  dlon  =  -1.0  *  dlon; 

while  (  est  dist  <  width  ) 

{ 

e->lon  +=  dlon; 

there . SetLef tRightAngleInDegrees (e- >lon  ) ; 

est  dist  =  earth->GetLineOfSightDistance (here, there) ; 

} 

e->lat  =  saved  lat; 
return  e; 

} 
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Table  B-3.  The  pyGFC.i  file. 


%module  pyGFC 

%{ 

#include  "pyGFC. h" 

%} 

%inGlude  "GFC.h" 

%include  "pyGFC. h" 

//  error  functions  from  the  math  lib. 
extern  double  erf (double  x) ; 
extern  double  erf c (double  x) ; 
extern  float  erff (float  x) ; 
extern  float  erfcf (float  x) ; 
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Disclaimer 


The  findings  in  this  report  are  not  to  be  eonstrued  as  an  offieial  Department  of  the  Army  position 
unless  so  designated  by  other  authorized  doeuments.  Citation  of  manufaeturer’s  trade  names 
does  not  eonstitute  an  offieial  endorsement  or  approval  of  the  use  thereof. 
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NO  OF 

COPIES  ORGANIZATION 

1  ADMNSTR 

ELEC  DEFNS  TECHL  INFO  CTR 
ATTN  DTICOCP 

8725  JOHN  J  KINGMAN  RD  STE  0944 
FT  BELVOIR  VA  22060-6218 

1  DARPA 

ATTN  IXO  S  WELBY 
3701  N  FAIRFAX  DR 
ARLINGTON  VA  22203-1714 

1  CD  OFC  OF  THE  SECY  OF  DEFNS 
ATTN  ODDRE  (R&AT) 

THE  PENTAGON 
WASHINGTON  DC  20301-3080 

1  US  ARMY  RSRCH  DEV  AND  ENGRG 

CMND 

ARMAMENT  RSRCH  DEV  AND 
ENGRG  CTR 

ARMAMENT  ENGRG  AND 
TECHNLGY  CTR 

ATTN  AMSRD  AAR  AEF  T  J  MATTS 
BLDG  305 

ABERDEEN  PROVING  GROUND  MD 
21005-5001 

1  US  ARMY  TRADOC 

BATTLE  LAB  INTEGRATION  & 
TECHL  DIRCTRT 
ATTN  ATCDB 
10  WHISTLER  LANE 
FT  MONROE  VA  23651-5850 

1  PM  TIMS,  PROFILER  (MMS-P) 

AN/TMQ-52 
ATTN  B  GRIFFIES 
BUILDING  563 
FT  MONMOUTH  NJ  07703 

1  US  ARMY  INFO  SYS  ENGRG  CMND 

ATTN  AMSEL  IE  TD  F  JENIA 
FT  HUACHUCA  AZ  85613-5300 

1  COMMANDER 

US  ARMY  RDECOM 
ATTN  AMSRD  AMR 
WC  MCCORKLE 
5400  FOWLER  RD 

REDSTONE  ARSENAL  AL  35898-5000 


NO  OF 

COPIES  ORGANIZATION 

1  US  GOVERNMENT  PRINT  OFF 

DEPOSITORY  RECEIVING  SECTION 
ATTN  MAIL  STOP  IDAD  J  TATE 
732  NORTH  CAPITOL  ST  NW 
WASHINGTON  DC  20402 

1  US  ARMY  RSRCH  LAB 

ATTN  AMSRD  ARE  Cl  OK  TP 
TECHL  LIB  T  LANDFRIED 
BLDG  4600 

ABERDEEN  PROVING  GROUND  MD 
21005-5066 

1  DIRECTOR 

US  ARMY  RSRCH  LAB 
ATTN  AMSRD  ARE  RO  EV 
WD  BACH 
PO  BOX  12211 

RESEARCH  TRIANGLE  PARK  NC 
27709 

1  SAM_BLACKBURN@POBOX.COM 

ELEC 


8  US  ARMY  RSRCH  LAB 

ATTN  AMSRD  ARE  Cl  N  G  RACINE 
ATTN  AMSRD  ARE  Cl  NT 
B  NGUYEN 

ATTN  AMSRD  ARE  Cl  NT  B  RIVERA 
ATTN  AMSRD  ARE  Cl  NT  N  IVANIC 
ATTN  AMSRD  ARE  Cl  NT  R  HARDY 
ATTN  AMSRD  ARE  Cl  OK  PE 
TECHL  PUB 

ATTN  AMSRD  ARE  Cl  OK  TL 
TECHL  LIB 
ATTN  IMNEALCIMS 
MAIL  &  RECORDS  MGMT 
ADELPHI  MD  20783-1197 

Total:  20  (2  ELEC,  1  CD,  17  HC) 
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